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Status of this Memo 
This memo defines an Experimental Protocol for the Internet 
community. It does not specify an Internet standard of any kind. 


Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2001). All Rights Reserved. 
IESG Note 


The IESG notes that the set of documents describing the RSIP 
technology imply significant host and gateway changes for a complete 
implementation. In addition, the floating of port numbers can cause 
problems for some applications, preventing an RSIP-enabled host from 
interoperating transparently with existing applications in some cases 
(e.g., IPsec). Finally, there may be significant operational 
complexities associated with using RSIP. Some of these and other 
complications are outlined in section 6 of the RFC 3102, as well as 
in the Appendices of RFC 3104. Accordingly, the costs and benefits 
of using RSIP should be carefully weighed against other means of 
relieving address shortage. 


Abstract 


This document contains an SLP service type template that describes 
the advertisements made by RSIP servers for their services. Service 
Location Protocol (SLP) is an IETF standards track protocol 
specifically designed to allow clients to find servers offering 
particular services. Since RSIP (Realm Specific IP) clients require 
a mechanism to discover RSIP servers, SLP is a natural match for a 
solution. The service type template is the basis for an Internet 
Assigned Numbers Authority (IANA) standard definition of the 
advertisements offered by RSIP servers, an important step toward 
interoperability. 
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1. Introduction 


Realm Specific IP (RSIP) [7] enables an RSIP client in one realm to 
borrow addresses and other resources from another realm. It does so 
by engaging in an RSIP protocol [1] exchange with an RSIP server. 
The RSIP protocol requires the RSIP server to have a permanent 
presence on both realms. 


There are a variety of traditional ways an RSIP client could go about 
locating the appropriate RSIP server. However, Service Location 
Protocol (SLP) [2][11] is an IETF standards track protocol 
specifically designed to facilitate location of services and their 
servers by clients. SLP provides a number of features that simplify 
locating RSIP servers. In this document, we describe how RSIP 
clients can use SLP to discover RSIP servers. 


2. Notation Conventions 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [4]. 


3. Terminology 


We reproduce here some SLP terminology from [2] for readers 
unfamiliar with SLP. 


User Agent (UA) 
A process working on the user’s behalf to establish contact with 


some service. The UA retrieves service information from the 
Service Agents or Directory Agents. 
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Service Agent (SA) 


A process working on behalf of one or more services to advertise 
the services and their capabilities. 


Directory Agent (DA) 


A process which collects service advertisements. There can only 
be one DA present per given host. 


Scope 


A set of services, typically making up a logical administrative 
group. 


Service Advertisement 


A URL, attributes, and a lifetime (indicating how long the 
advertisement is valid), providing service access information and 
capabilities description for a particular service. 


4. Using SLP for RSIP Service Discovery 


SLP provides the framework in which RSIP clients and servers make 
contact. Here is a description of how an RSIP server and client find 
each other using SLP: 


1. The RSIP server implements a SLP SA while the RSIP client 
implements an SLP UA. 


2. The RSIP SA constructs a service advertisement consisting of a 
service URL, attributes and a lifetime. The URL has service type 
"service:rsip", and attributes defined according to the template 
in Section 7. 


3. If an SLP DA is found, the SA contacts the DA and registers the 
advertisement. If no DA is found, the SA maintains the 
advertisement itself, answering multicast UA queries directly. 


4. When the RSIP client requires contact information for an RSIP 
server, the UA either contacts the DA using unicast or the SA 
using multicast. The UA includes a query based on the attributes 
to indicate the characteristics of the server it requires. 


5. Once the UA has the host name or address of the RSIP server as 
well as the port number, it can begin negotiation using the RSIP 
protocol. 
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This procedure is exactly the same for any client/server pair 
implementing SLP and is not specific to RSIP. 


Many protocols use a variety of traditional methods for service 
discovery. These methods include static configuration, purpose-build 
protocols for discovery, special features in the protocol itself, DNS 
SRV RRs [5], or DHCP [6]. SLP provides a number of advantages over 
these traditional methods: 


1. Discovery of services using SLP is dynamic, whereas many of the 
traditional methods only allow static or weakly dynamic (i.e., 
difficult to update) discovery. Clients only discover services 
that are actually active with SLP. Furthermore, if subsequent to 
initial discovery a server goes down, the client can reissue an 
SLP query and obtain a new server. On the server side, no 
databases must be updated to provide dynamic discovery, the 
servers advertise themselves. 


2. SLP requires no third party configuration. Only the server 
offering the service and the client seeking it are required to 
know the details for the particular service type. 


3. SLP allows clients to specify the attributes describing the 
desired server. A client discovers servers that meet a set of 


specific requirements. This reduces the amount of network traffic 
involved in selecting a server when many possible choices are 
available. 


4. SLP contains a number of scaling mechanisms (DAs, scopes, 
multicast convergence algorithm), that facilitate deployment in 
large enterprise networks as well as in smaller networks. 


5. Using Scopes for Server Provisioning 


One particular design feature of SLP that is useful for RSIP is 
scopes. Scopes in SLP are a mechanism for provisioning access to 
particular service advertisements. An administrator assigns UAs and 
SAs to particular scopes to assure that UAs only find SAs in those 
scopes. Scopes are not an access control mechanism for the service 
itself, however. UAs from outside the scope can still access 
services in a particular scope (unless the service itself provides 
for access control), they just won’t be able to find the services 
using SLP. 


Scopes are useful for RSIP service advertisement provisioning because 
they allow a system administrator to tie particular RSIP clients to 
specific RSIP servers. For example, consider the network 
architecture described in Section 4.2.1 of [7]. RSIP clients are 
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recommended to find "the nearest" RSIP server, but exactly how that 
should be arranged is left unspecified. SLP provides a way for 
system administrators to precisely specify which realm an RSIP client 


resides in, by tying the realm t 
Section 14.1 is reproduced here, 
illustrate how clients could be 
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Clients on the upper 10.0.0.0/8 
scope B, 
to use SLP scope C. RSIP server 
use SLP to locate RSIP server A, 


10.0.1.0/24 and 10.0.2.0/24 subnets. 


o an SLP scope. The diagram from 
with SLP scopes included to 
directed to the right RSIP servers. 


--------- + 
RSIP 
server +---- 10.0.0.0/8 
B | SLP Scope: B 
---+----- + 
10.0.1.0/24 
+ (149.112.240.0/25) 
+--+ 
| SLP Scope: A 
+--+ 
+ 10.0.2.0/24 
| (149.112.240.128/25) 
---+----- + 
RSIP | 
server +---- 10.0.0.0/8 
C | SLP Scope: C 
--------- + 


network are configured to use SLP 


while clients on the lower 10.0.0.0/8 network are configured 


s B and C (as clients of server A) 
as do other RSIP clients on the 


Within these two subnets, all 


clients have their scopes configured to be A. 


Note that specifying a particula 
restrict the SLP scope for other 
can be configured for multiple s 


r SLP scope for RSIP clients does not 
services advertised by SLP. SLP UAs 
copes, so the scope configured for 


printing may be different from the scope configured for RSIP service. 


Since SLP scopes are configured through a DHCP option [8], 


the IP address, system administr 


along with 
ators can easily switch a cluster of 


machines from one realm to another by simply changing the scope and 
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IP address assignments on the DHCP server. For example, in the above 
architecture, suppose a system administrator wanted to remove RSIP 
server B so that clients on the upper 10.0.0.0/8 subnet were directly 
on subnet 10.0.1.0/24. These clients now communicate with RSIP 
server A. By simply changing the address assignments and scope 
configuration of these clients on the DHCP server, the realm can be 
effectively switched. 


6. Load Balancing 


While SLP itself contains no specific provision for load balancing, 
load balancing can easily be implemented using SLP. The only 
requirement is that the service type template specify an attribute 
indicating server load. In the case of RSIP, the service type 
template in Section 7 contains such an attribute. The attribute 
indicates the number of RSIP client sessions currently being 
supported by the server. 


In order to perform load balancing, the RSIP server must update its 
service advertisement periodically as new connections are accepted. 
An RSIP client seeking to find the server having the lightest load 
performs the following series of SLP operations. 


1. As in Section 4, the client issues an SLP service request and 
collects all the returned service URLs. 


2. For each service URL, the client performs an SLP attribute request 
for the attribute LOAD. The integer load figures are returned. 


3. The client sorts through the returned load figures and selects the 
URL having the least number of connections. The client 
establishes its RSIP session with that server. 


Because of network delays, this procedure does not guarantee that a 
client will always obtain a connection with the lightest loaded 
server, but it does provide a high probability that the selected 
server is more lightly loaded. 


A similar procedure is used in [9] to load balance access to TN3270E 
telnet servers. 
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7. The RSIP Service Type Template 


Name of submitters: James Kempf <james@docomolabs-—usa.com> 
Gabriel Montenegro <gab@sun.com> 


Language of service template: en 


Security Considerations: 
RSIP clients can use Service Location Protocol to find RSIP 


servers having particular security characteristics. If secure 
access to such information is required, SLP security should be 
used. 
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Template text: 
template-type = rsip 
template-version = 0.0 


template-description= 
The service:rsip type provides advertisements for clients seeing 
realm-specific IP (RSIP) servers. RSIP servers use the Realm 
Specific IP protocol to manage addresses and other resources 
from one realm on behalf of a client in another realm. 


template-url-syntax= 
;No additional URL path information required. An example service 
;URL for an RSIP server is: service:rsip://gateway.mydomain: 4455 


ipsec-support = BOOLEAN O 
#True if the server supports IPSEC as per [10] 


ike-support = BOOLEAN O 
#True if the server supports IKE as per [10] 


tunnel-type = STRING LM O 

IP-IP 
#The tunneling methods supported by the RSIP server. Clients 
#should include this attribute in a query so that they obtain a 
#server offering a tunneling method for which they have 
#support. Default is IP-IP. The values are currently 
#restricted to IP-IP, L2TP, GRE and NONE. A server can support 
#multiple tunnel types. 

IP-IP, L2TP, GRE, NONE 


transport = STRING LM O 
TCP 

#Transport used by the RSIP protocol itself. 
TCP, UDP 


load = INTEGER O 
#If the server supports load balancing, this attribute should be 
#set to an integer from 0 to 100. 0 is the lowest indication of 
#load and 100 the highest. Clients can query for this attribute 
#and obtain load information, from which they can make an 
#intelligent decision about which server to use. 

BB SAe SSS Se Hees SSS 5452 template ends here --------------------------- 
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8. 


Security Considerations 


Service type templates provide information that is used to interpret 
information obtained by clients through SLP. If the RSIP template is 
modified or if a false template is distributed, RSIP servers may not 
correctly register themselves, or RSIP clients may not be able to 
interpret service information. 


SLP provides an authentication mechanism for UAs to assure that 
service advertisements only come from trusted SAs [2]. If trust is 
an issue, particularly with respect to the information sought by the 
client about IPSEC and IKE support, then SLP authentication should be 
enabled in the network. 


Summary 


This document describes how SLP can be used by RSIP clients to find 
RSIP servers. A service type template for an RSIP SLP service type 
is presented. In addition, a few techniques for provisioning access 
to service advertisements for particular gateway servers, and for 
load balancing using SLP were provided. The result should allow RSIP 
service provisioning that is considerably more dynamic and robust 
than when traditional service discovery mechanisms are used. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2001). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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